Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.

Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.

Архитектура растянутого кластера в общем случае выглядит так:

Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.

Для этих соединений рекомендуются следующие параметры:

Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).

В среде растянутого кластера данные виртуальной машины всегда читаются с локальных узлов VSAN - это называется Read Locality. Ну а для операций записи, само собой, нужна определенная пропускная способность на другую площадку. Она рассчитывается как:

B = Wb * md * mr

где:

• Wb - полоса записи данных.
• md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
• mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.

Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:

Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps

Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.

Теперь считаем требуемую пропускную способность канала между площадками:

B = Wb * md * mr = 320 Mbps * 1,4 * 1,25 = 560 Mbps

Ну а в самом документе вы найдете еще больше интересных расчетов и примеров.

Компания VMware выпустила очень познавательный документ "An overview of VMware Virtual SAN caching algorithms", который может оказаться полезным всем тем, кто интересуется решением для создания программных хранилищ под виртуальные машины - VMware Virtual SAN. В документе описан механизм работы кэширования, который опирается на производительные SSD-диски в гибридной конфигурации серверов ESXi (то есть, SSD+HDD).

SSD-диски используются как Performance tier для каждой дисковой группы, то есть как ярус производительности, который преимущественно предназначен для обеспечения работы механизма кэширования на чтение (Read cache, RC). По умолчанию для этих целей используется 70% емкости SSD-накопителей, что экспериментально было определено компанией VMware как оптимальное соотношение.

SSD-диски значительно более производительны в плане IOPS (тысячи и десятки тысяч операций в секунду), поэтому их удобно использовать для кэширования. Это выгодно и с экономической точки зрения (доллары на IOPS), об этом в документе есть наглядная табличка:

То есть, вы можете купить диск SSD Intel S3700 на 100 ГБ за $200, который может выдавать до 45 000 IOPS, а это где-то $0,004 за IOPS. С другой же стороны, можно купить за те же $200 диск от Seagate на 1 ТБ, который будет выдавать всего 100 IOPS, что составит $2 на один IOPS.

Кэш на чтение (RC) логически разделен на "cache lines" емкостью 1 МБ. Это такая единица информации при работе с кэшем - именно такой минимальный объем на чтение и резервирование данных в памяти используется. Эта цифра была высчитана экспериментальным путем в исследовании нагрузок на дисковую подсистему в реальном мире, которое VMware предпочитает не раскрывать. Кстати, такой же величины объем блока в файловой системе VMFS 5.x.

Помимо обслуживания кэша на SSD, сервер VMware ESXi использует небольшой объем оперативной памяти (RAM) для поддержки горячего кэша обслуживания этих самых cache lines. Он содержит несколько самых последних использованных cache lines, а его объем зависит от доступной памяти в системе.

Также в памяти хранятся некоторые метаданные, включая логические адреса cache lines, валидные и невалидные регионы кэша, информация о сроке хранения данных в кэше и прочее. Все эти данные постоянно хранятся в памяти в сжатом виде и никогда не попадают в своп. При перезагрузке или выключении/включении хоста кэш нужно прогревать заново.

Итак, как именно работает кэширование на SSD в VMware Virtual SAN:

1. Когда операция чтения приходит к Virtual SAN, сразу же включается механизм определения того, находятся ли соответствующие данные в кэше или нет. При этом запрашиваемые данные за одну операцию могут быть больше одной cache line.

2. Если данные или их часть не находятся в RC, то для них резервируется буфер нужного объема с гранулярностью 1 МБ (под нужное количество cache lines).

3. Новые аллоцированные cache lines вытесняют из кэша старые в соответствии с алгоритмом Adaptive Replacement Cache (ARC), который был лицензирован VMware у IBM.

4. В случае промаха кэша каждое чтение одной cache line с HDD разбивается на чанки размером 64 КБ (этот размер тоже был определен экспериментально в ходе исследований). Это сделано для того, чтобы не забивать очередь на чтение с HDD "жирной" операцией чтения в 1 МБ, которая бы затормозила общий процесс ввода-вывода на диск.

5. В общем случае, одна операция чтения запрашивает лишь часть данных одной cache line, а первыми читаются именно нужные 64 КБ чанки с HDD-диска от этой cache line.

6. Запрошенные с HDD-диска данные сразу отдаются к подсистеме вывода и направляются туда, откуда их запросили, а уже потом в асинхронном режиме они попадают в соответствующие cache lines кэша и под каждую из них выделяется буфер 1 МБ в памяти. Таким образом устраняются потенциальные затыки в производительности.

В документе описаны также и механики работы кэша на запись (Write cache), для которого используется техника write-back, а также рассматриваются All Flash конфигурации. Читайте - это интересно!

Многие из вас знают утилиту esxtop (о которой мы часто пишем), позволяющей осуществлять мониторинг производительности сервера VMware ESXi в различных аспектах - процессорные ресурсы, хранилища и сети. Многие администраторы пользуются ей как раз для того, чтобы решать проблемы производительности.

Но оказывается, что использование esxtop само по себе может тормозить работу сервера VMware ESXi!

Это может произойти в ситуации, если у вас к ESXi смонтировано довольно много логических томов LUN, на обнаружение которых требуется более 5 секунд. Дело в том, что esxtop каждые 5 секунд повторно инициализирует объекты, с которых собирает метрики производительности. В случае с инициализацией LUN, которая занимает длительное время, запросы на инициализацию томов будут складываться в очередь. А как следствие (при большом числе томов) это будет приводить к возрастанию нагрузки на CPU и торможению - как вывода esxtop, так и к замедлению работы сервера в целом.

Выход здесь простой - надо использовать esxtop с параметром -l:

# esxtop -l

В этом случае данная утилита ограничит сбор метрик производительности только теми объектами, которые были обнаружены при первом сканировании. Соответственно, так лучше всего ее и использовать, если у вас к серверу VMware ESXi прицеплено много хранилищ.

На днях компания VMware выпустила полезный документ о лучших практиках по использованию "растянутых" кластеров на базе решения для создания отказоустойчивых хранилищ - "VMware Virtual SAN Stretched Cluster Performance and Best Practices".

Напомним также, что не так давно мы писали про конфигурацию VMware HA Stretched Cluster вместе с отказоустойчивыми хранилищами Virtual SAN.

Как и другие документы этой серии, этот whitepaper богат различными графиками и диаграммами, касающимися производительности решения. Например, вот производительность обычного кластера VMware Virtual SAN 6.1 и растянутого с задержками (latency) в 1 мс и 5 мс:

Основные моменты, раскрываемые в документе:

• Развертывание и настройка Virtual SAN Stretched Cluster
• Производительность растянутого кластера в сравнении с обычным
• Производительность кластера при различных отказах (хост, сайт целиком)
• Лучшие практики использования растянутых кластеров

Больше 5 лет назад мы писали о технологии VMware Storage I/O Control (SIOC), которая позволяет приоритизировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены. С тех пор многие администраторы применяют SIOC в производственной среде, но не все из них понимают, как именно это работает.

На эту тему компания VMware написала два интересных поста (1 и 2), которые на практических примерах объясняют, как работает SIOC. Итак, например, у нас есть вот такая картинка:

В данном случае мы имеем хранилище, отдающее 8000 операций ввода-вывода в секунду (IOPS), к которому подключены 2 сервера ESXi, на каждом из которых размещено 2 виртуальных машины. Для каждой машины заданы параметры L,S и R, обозначающие Limit, Share и Reservation, соответственно.

Напомним, что:

• Reservation - это минимально гарантированная производительность канала в операциях ввода-вывода (IOPS). Она выделяется машине безусловно (резервируется для данной машины).
• Shares - доля машины в общей полосе всех хостов ESXi.
• Limit - верхний предел в IOPS, которые машина может потреблять.

А теперь давайте посмотрим, как будет распределяться пропускная способность канала к хранилищу. Во-первых, посчитаем, как распределены Shares между машинами:

Общий пул Shares = 1000+2500+500+1000 = 5000

Значит каждая машина может рассчитывать на такой процент канала:

VM1 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS
VM2 = 2500/5000 = 50% = 0,5 * 8000 = 4000 IOPS
VM3 = 500/5000 = 10% = 0,1 * 8000 = 800 IOPS
VM4 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS

Если смотреть с точки зрения хостов, то между ними канал будет поделен следующим образом:

ESX1 = 3500/5000 = 70%
ESX2 = 1500/5000 = 30%

А теперь обратимся к картинке. Допустим у нас машина VM1 простаивает и потребляет только 10 IOPS. В отличие от планировщика, который управляет памятью и ее Shares, планировщик хранилищ (он называется mClock) работает по другому - неиспользуемые иопсы он пускает в дело, несмотря на Reservation у это виртуальной машины. Ведь он в любой момент может выправить ситуацию.

Поэтому у первой машины остаются 1590 IOPS, которые можно отдать другим машинам. В первую очередь, конечно же, они будут распределены на этом хосте ESXi. Смотрим на машину VM2, но у нее есть LIMIT в 5000 IOPS, а она уже получает 4000 IOPS, поэтому ей можно отдать только 1000 IOPS из 1590.

Следовательно, 590 IOPS уйдет на другой хост ESXi, которые там будут поделены в соответствии с Shares виртуальных машин на нем. Таким образом, распределение IOPS по машинам будет таким:

VM1 = 10 IOPS
VM2 = 4000+1000 = 5000 IOPS (так как установлен Limit)
VM3 = 800 + ((500/1500) * 590) = 997 IOPS
VM4 = 1600 + ((1000/1500) * 590) = 1993 IOPS

Все просто и прозрачно. Если машина VM1 начнет запрашивать больше канала, планировщик mClock начнет изменять ситуацию и приведет ее к значениям, описанным выше.

Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.

В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:

Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.

Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:

Смотрим, что получится и нажимаем Ok:

Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:

Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.

Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.

Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.

К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.

Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:

Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.

Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.

Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.

Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!

Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:

В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).

Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.

Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:

Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:

Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:

Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.

Еще в самом конце августа компания VMware выпустила весьма достойный внимания документ "VMware vCenter Server Performance and Best Practices", рассказывающий о лучших практиках по использованию сервера vCenter версии 6 в контексте производительности. Напомним, что ранее мы уже писали про еще один документ о vCenter - "VMware vCenter Server 6.0 Cluster Performance".

Основные моменты документа:

• vCenter Server 6.0 имеет существенно большую производительность, чем предыдущая версия vCenter Server 5.5. Некоторые операции исполняются почти в 2 раза быстрее, а отображение страниц в Web Client работает на 90% быстрее.
• vCenter Server Appliance работает почти так же быстро, как и полноценный vCenter Server для Windows.
• Ресурсы, выделенные для vCenter (CPU, память, диск и полоса пропускания сети) влияют на размер доступного в vCenter окружения и скорость исполнения операций.
• Используя рекомендации из документа и правильно выделяя ресурсы в зависимости от нагрузки, пользователи могут значительно повысить производительность стандартной конфигурации VMware vCenter.

Скачать документ "VMware vCenter Server Performance and Best Practices" можно по этой ссылке.

Совсем недавно компания VMware выпустила интересный документ о производительности операций виртуальной инфраструктуры под управлением VMware vCenter 6 для серверов, работающих в кластере HA/DRS - "VMware vCenter Server 6.0 Cluster Performance".

Упор сделан на сравнение производительности свежей версии vCenter 6.0 с предшественником - vCenter 5.5. Напомним, что шестая версия поддерживает до 64 хоста ESXi в кластере и до 8000 виртуальных машин (до этого было 32 хоста ESXi и 3000 виртуальных машин).

Конфигурация тестовой среды была следующей:

Программные компоненты:

Производительность каких операций проверялась:

• Add Port Group
• Remove Port Group
• Clone VM
• Create Folder
• Delete Folder
• Create Snapshot
• Delete Snapshot
• Group Power-On VMs
• vMotion VM
• Power On VM
• Power Off VM
• Reconfigure VM
• Register VM
• Unregister VM
• Relocate VM
• Remove VM
• Reset VM
• Suspend VM
• Resume VM

В результате тестирования были получены следующие результаты:

• vCenter 6.0 показывает лучшую операционную производительность (в количестве операций) до 66% лучше прошлой версии.

• Улучшенная производительность под очень тяжелыми нагрузками.
• Одинаковая производительность как vCenter Server для Windows, так и виртуального модуля vCSA на базе Linux.
• Операции с виртуальными машинами происходят существенно быстрее.

Больше интересных подробностей и графиков вы можете найти в документе.

Недавно компания VMware выпустила очень интересный документ "What’s New in VMware vSphere 6 - Performance", в котором рассказывается о том, какие улучшения были сделаны в новой версии vSphere 6.0, касающиеся различных аспектов производительности платформы (вычислительные ресурсы, хранилища и сети).

Документ выпущен отделом технического маркетинга VMware, и в нем приведены вполне конкретные сведения об увеличении производительности компонентов vSphere.

Например, вот сводная картинка улучшения производительности vCenter (версия 6.0 против 5.5) при тяжелых нагрузках на Microsoft SQL Server 2012 в зависимости от числа объектов, которые находятся под управлением сервиса (размер Inventory). Данные приведены в количестве операций в минуту. Результаты впечатляют:

Улучшения кластеров отказоустойчивых хранилищ VMware Virtual SAN (результаты по конфигурации All-Flash еще не обработаны):

С точки зрения производительности виртуальных сетевых адаптеров VMXNET 3, платформа vSphere 6.0 научилась выжимать из них более 35 гигабит в секунду при работе с физическими адаптерами 40 GbE:

Ну и в целом в документе есть еще много чего интересного - скачивайте.

Послезавтра, 21 июля, компании Mellanox и StarWind проведут интересный вебинар "100 GbE Performance at 10 GbE Cost", посвященный построению решения для хранилищ виртуальных машин впечатляющей производительности (да-да, 100 GbE, Карл!).

Мероприятие пройдет 21 июля, в 21-00 по московскому времени:

Приходите на вебинар, чтобы узнать, как по цене 10 GbE-решения построить сеть 40 GbE на базе продуктов Mellanox (Infiniband/Ethernet) и добиться в ней 100 GbE производительности за счет решений компании StarWind (в частности, продукта Virtual SAN). Вебинар со стороны StarWind проводит Макс Коломейцев, так что вы можете задавать вопросы на русском языке.

Узнайте, сколько IOPS может выжать StarWind из сетевой архитектуры Mellanox - регистрируйтесь на вебинар "100 GbE Performance at 10 GbE Cost".

Если вы администратор платформы виртуализации VMware vSphere, то, наверное, часто замечали, что в некоторых случаях при операциях с виртуальными машинами и ее дисками происходит "подмораживание" ВМ (или "stun", он же "quiescence"). В этот момент виртуальная машина ничего не может делать - она недоступна для взаимодействия (в консоли и по сети), а также перестает на небольшое время производить операции ввода-вывода. То есть, ее исполнение ставится на паузу на уровне инструкций, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).

Cormac Hogan написал на эту тему интересный пост. Stun виртуальной машины нужен, как правило, для того, чтобы сделать ее на время изолированной от окружающего мира для выполнения значимых дисковых операций, например, консолидация снапшотов. Это может занимать несколько секунд (и даже десятков), но часто это происходит на время около секунды и даже меньше.

Когда может возникать stun виртуальной машины? Есть несколько таких ситуаций.

1. Во время операции "suspend" (постановка ВМ на паузу). Тут происходит такое подмораживание, чтобы скинуть память ВМ на диск, после чего перевести ее в приостановленное состояние.

2. В момент создания снапшота. Об этом написано выше - нужно закрыть старый диск и начать писать в новый. На время этой операции логично, что приостанавливается ввод-вывод.

3. Консолидация снапшотов (удаление всех). Здесь тоже нужно "склеить" все VMDK-диски (предварительно закрыв) и начать работать с основным диском ВМ. А вот удаление снапшота в цепочке stun не вызывает, так как не затрагивает VMDK, в который сейчас непосредственно идет запись.

4. Горячая миграция vMotion. Сначала память передается от одной машины к целевой ВМ без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).

5. Горячая миграция хранилищ Storage vMotion. Здесь stun случается аж дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова переоткрыть диски уже на целевом хранилище.

В современных версиях vSphere работа со снапшотами была оптимизирована, поэтому подмораживания виртуальной машины во время этих операций вы почти не заметите.

Практически все администраторы виртуальных инфраструктур обеспокоены проблемой ее производительности в тех или иных условиях. На днях компания VMware обновила свое основное руководство по производительности платформы виртуализации номер один на рынке - Performance Best Practices for VMware vSphere 6.0.

Это не просто очередной whitepaper - это настоящая книга о производительности, на почти 100 страницах которой можно найти не только теоретические советы, но и вполне практичные настройки и конфигурации среды VMware vSphere. К каждому объясняемому параметру заботливо описаны рекомендуемые значения. В общем, Must Read.

Многие наши читатели интересуются, а есть ли утилиты, предназначенные специально для облачных инфраструктур. Например, которые позволяют оценить качество предоставления услуг сервис-провайдером? Да, есть такое, и одно из подобных средств - AppEnsure - как раз позволяет измерять время отклика для корпоративных приложений и текущую используемую пропускную способность.

Эта штука появилась еще весной в рамках программы Citrix Startup Accelerator, где было вот такое видео:

Теперь это полноценный продукт, с платным и бесплатным изданиями, который позволяет анализировать качество предоставления услуг облаком (частным или публичным) и искать причину падения производительности приложений.

Вот возможности бесплатной версии AppEnsure:

• Обнаружение приложений вашей инфраструктуры и их добавление в окружение мониторинга.
• Автоматическое построение топологии зависимости компонентов вашего приложения.
• Измерение по шагам (hop-by-hop) и полного (end-to-end) времени отклика, а также пропускной способности канала для каждого приложения.
• Возможность предоставления диагностической информации при снижении пропускной способности или увеличении времени отклика.
• Продукт AppEnsure (консоль и база данных) поставляется как готовый виртуальный модуль (VMware Virtual Appliance).
• Доступны как серверные, так и десктопные агенты для ОС Windows/Linux (до 5 серверов в бесплатной версии).
• Поддержка удаленных агентов (в другой сети или облаке по отношению к мастер-инсталляции).
• Доступ к веб-порталу технической поддержки.
• Сохранение данных в течение 24 часов (в платной версии - сколько угодно).

Вот так выглядит обнаруженная топология:

Так дэшборд приложения:

А вот так - общий дэшборд:

Ну и таблица сравнения изданий:

Загрузить бесплатную версию AppEnsure или попробовать платную версию продукта можно по этой ссылке.

Мы точно знаем, что вам всем интересно узнать, какова же реальная производительность продукта номер 1 для создания отказоустойчивых программных хранилищ StarWind Virtual SAN. Поэтому-то и приглашаем вас на бесплатный вебинар "Get Unbelievable Performance without Expensive All-Flash Arrays", где вы узнаете как достичь высокой производительности подсистемы хранения виртуальных машин, не покупая дорогостоящие All-flash хранилища.

Вебинар пройдет 16 июня в 21-00 по московскому времени. Мероприятие проводит продакт-менеджер StarWind Макс Коломейцев. Вопросы можно задавать на русском языке! Регистрируйтесь!

Интересная история произошла тут между компаниями VMware и Nutanix. Инженеры и сейлы из VMware решили провести сравнение производительности программных отказоустойчивых кластеров на базе локальных хранилищ серверов VMware Virtual SAN и Nutanix. Создав тестовую конфигурацию и выбрав профиль нагрузки, компания VMware сделала тест в средах Virtual SAN и Nutanix.

Кстати, вот конфигурация тестового кластера хранилищ:

• 4 x Dell XC630-10 для Nutanix,
• 4 x Dell R630 для vSphere с кластером VSAN
• 2 x Intel E5-2690 v3 на сервер
• 12 ядер на процессор 2.6GHz, 256 ГБ памяти на сервер
• Двухпортовый 10Gb Ethernet
• 1 x PERC H730 Mini на сервер
• 2 x 400GB Intel S3700 на сервер
• 6 дисков x 1TB 7200 RPM NL-SAS (Seagate) на сервер

Но тут спецы из VMware решили заглянуть в EULA Nutanix, а там написано (п. 2.1, подпункт e):

You must not disclose the results of testing, benchmarking or other performance or evaluation information related to the Software or the product to any third party without the prior written consent of Nutanix

То есть, публиковать результаты тестирования нельзя. Вот такой облом. А ведь VMware много раз ругали за то, что она сама запрещает публиковать результаты тестирования производительности с конкурирующими продуктами. Это также зафиксировано в EULA:

You may use the Software to conduct internal performance testing and benchmarking studies. You may only publish or otherwise distribute the results of such studies to third parties as follows: (a) if with respect to VMware’s Workstation or Fusion products, only if You provide a copy of Your study to benchmark@vmware.com prior to distribution; (b) if with respect to any other Software, only if VMware has reviewed and approved of the methodology, assumptions and other parameters of the study (please contact VMware at benchmark@vmware.com to request such review and approval) prior to such publication and distribution.

VMware, конечно, утверждает, что у нее условия мягче, но по-сути у них написано одно и то же. Публиковать результаты тестов без разрешения нельзя. А разрешение, конечно, никто не даст, так как опубликовать конкуренты захотят только, если у них все работает лучше и быстрее.

Поэтому VMware ничего не оставалось, как опубликовать результаты только своих тестов и разбить их по профилям нагрузки, отметив, что желающие сравнить пользователи сами могут убедиться, что Nutanix работает медленнее, проведя тесты самостоятельно.

Надо также отметить, что VMware отправила запрос на публикацию в Nutanix, на что получила ожидаемый ответ - публиковать нельзя.

Ну и, собственно, результаты тестирования для кластера Virtual SAN:

Совсем недавно компания VMware выпустила полезный документ "VMware Horizon View 6.0.2 and VMware Virtual SAN 6.0 Hybrid", описывающий эталонную архитектуру инфраструктуры виртуальных ПК Horizon View 6, которые хранятся в кластере отказоустойчивости VMware Virtual SAN 6.0, построенном на базе хостов VMware ESXi.

В документе рассмотрено тестирование производительности 12-узлового кластера Virtual SAN на базе серверов Supermicro в рамках следующей логической архитектуры:

Подробная конфигурация хостов:

В целом инфраструктура тестирования выглядела так:

Для тестов использовалось средство Login VSI (о нем мы уже много писали), которое поставляется вместе с методологией тестирования:

Сводные результаты тестов:

Для получения более подробной информации о результатах по каждому тесту, используемых сценариях и конфигурациях обращайтесь к документу. Все 38 страниц полны картинок, графиков и табличек с цифрами - док составлен очень по делу. Для тех, кто планирует VDI на базе Virtual SAN очень полезный референс, как в плане архитектуры, так и в плане производительности.

На днях компания VMware выпустила интересный открытый документ "Virtualizing Microsoft Applications on VMware Virtual SAN", в котором описываются результаты тестирования бизнес-критичных приложений Microsoft в кластере отказоустойчивых хранилищ VMware VSAN.

В документе рассматривается стрессовое тестирование следующих приложений, работающих в кластере Virtual SAN, состоящем из 8 узлов:

• Microsoft Exchange 2013 с поддержкой Database Availability Groups (DAG)
• Microsoft SQL Server 2014 с включенными AlwaysOn Availability Groups (AAG)
• Microsoft SharePoint 2013 как фронтэнд баз данных

Для теста использовалась такая конфигурация серверов:

• ESX host CPU - 2 x Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz 10C (60 GHz)
• ESX host RAM - 256 GB
• Network Adapter - 2x Intel Ethernet 82599EB 10-Gigabit SFI/SFP+
• Storage Adapter - 2x LSI Logic / Symbios Logic LSI-9300-8i
  • Firmware version: 6.00.00.00-IT
  • Driver version: MPT3SAS
• Power Management - Balanced (поставлено в BIOS)
• Disks SSD - 2x Intel 400 GB (SSDSC2BA400G3)
• SSD - 2x Intel 200GB (Intel PCIe 910)
• HDD - 12 x Seagate 900 GB

Конфигурация дисковых групп кластера Virtual SAN:

• Diskgroup 1 - 1x Intel 400GB 3x Seagate 900GB
• Diskgroup 2 - 1x Intel 400GB 3 x Seagate 900GB
• Diskgroup 3 - 1x Intel 200GB 3 x Seagate 900GB
• Diskgroup 4 - 1x Intel 200GB 3 x Seagate 900GB

Для тестирования Microsoft Exchange применялись следующие средства:

• Microsoft Exchange Load Generator 2013
• Microsoft Exchange Server Jetstress 2013 Tool (с использованием руководства Microsoft Exchange Server Jetstress 2013 Field Guide).

Архитектура сервисов Exchange:

Конфигурация виртуальных машин:

Результаты тестирования первого узла с ролью Mailbox средствами Jetstress:

Результаты тестирования второго узла с ролью Mailbox:

Результаты теста Load Generator:

Архитектура сервисов Microsoft SQL Server с технологией защиты данных Always On:

Для тестирования SQL Server использовался инструмент DVD Store. Конфигурация виртуальных машин:

Результаты тестов DVD Store.

Ну и в заключение - сводные результаты тестирования:

В итоге утверждается, что приложения Microsoft уровня Tier 1 прекрасно себя чувствуют в кластере VMware Virtual SAN, и их быстродействие мало чем отличается от ситуации, если бы на бэкэнде были аппаратные SAN/NFS-массивы.

За остальными подробностями обращайтесь к документу "Virtualizing Microsoft Applications on VMware Virtual SAN".

Не так давно мы писали про средство Login VUM, которое позволяет в реальном времени создавать нагрузку в виртуальном ПК для различных приложений (то есть открывать окна, выполнять некоторые операции), будто бы за этой виртуальной машиной работает реальный пользователь. Далее, если время выполнения стандартных операций превышает некоторые пороговые значения (например, приложение запускается слишком долго), Login VUM оповещает системного администратора о возникшей проблеме. Из коробки измеряется время запуска таких приложений, как Microsoft Office, Internet Explorer и Adobe Reader, но скрипты можно настроить на использование любых приложений.

Теперь компания Login VSI выпустила финальную версию этого решения, которое теперь называется Login PI.

Основные варианты использования Login PI:

• Мониторинг производительности продуктивных окружений без влияния на работающие системы предприятия.
• Оповещения о снижении производительности VDI-инфраструктуры (неважно, Citrix, VMware или другого вендора).
• Регулярное тестирование VDI-среды для понимания ее текущего уровня производительности и занятости ресурсов.

Интересный момент - Login PI можно протестировать в реальном времени (hands-on lab) прямо на сайте Login VSI. Для этого нужно заполнить форму вот тут, после чего вам предоставят доступ к тестовой лаборатории, где вы сможете самостоятельно поработать с данным продуктом, управляя консолями двух виртуальных машин:

Руководство по использованию этой тестовой лаборатории можно почитать вот тут.

Login PI основан на фреймворке Login VSI (технология измерений VSImax), который уже надежно зарекомендовал себя для задач тестирования инфраструктуры виртуальных ПК (об этом мы писали ранее). Для запроса 30-дневной триальной версии Login PI используйте вот эту ссылку.

Как вы знаете, в обновленной версии платформы виртуализации VMware vSphere 6.0 появились не только новые возможности, но и были сделаны существенные улучшения в плане производительности (например, вот).

В компании VMware провели тест, использовав несколько виртуальных машин с базами данных SQL Server, где была OLTP-модель нагрузки (то есть большой поток небольших транзакций). Для стресс-теста БД использовалась утилита DVD Store 2.1. Архитектура тестовой конфигурации:

Сначала на хосте с 4 процессорами (10 ядер в каждом) запустили 8 виртуальных машин с 8 vCPU на борту у каждой, потом же на хосте 4 процессорами и 15 ядер в каждом запустили 8 ВМ с 16 vCPU. По количеству операций в минуту (Operations per minute, OPM) вторая конфигурация показала почти в два раза лучший результат:

Это не совсем "сравнение яблок с яблоками", но если понимать, что хосты по производительности отличаются не в два раза - то результат показателен.

Интересен также эксперимент с режимом Affinity у процессоров для "большой" виртуальной машины. В первом случае машину с 60 vCPU привязали к двум физическим процессорам хоста (15 ядер на процессор, итого 30 ядер, но использовалось 60 логических CPU - так как в каждом физическом ядре два логических).

Во втором же случае дали машине те же 60 vCPU и все оставили по дефолту (то есть позволили планировщику ESXi шедулить исполнение на всех физических ядрах сервера):

Результат, как мы видим, показателен - физические ядра лучше логических. Используйте дефолтные настройки, предоставьте планировщику ESXi самому решать, как исполнять виртуальные машины.

Больше информации об этом тесте можно узнать из документа "Performance Characterization of Microsoft SQL Server on VMware vSphere 6".

Как вы знаете, недавно вышла новая версия платформы виртуализации VMware vSphere 6.0, для которой было также обновлено средство создания кластеров хранилищ VMware Virtual SAN 6.0 на базе локальных дисков серверов. Среди прочих новых возможностей VSAN, было сказано об улучшении производительности решения, что и решили проверить коллеги на тестах вот тут.

Тест проводился дома и не претендует на какую-либо достоверность, но, все же, его весьма интересно посмотреть. Автор взял 3 узла Shuttle SZ87R6 следующей конфигурации (надо отметить, что они не в HCL):

В качестве коммутатора использовался Cisco SG300.

Для тестирования были использованы следующие гипервизоры:

• ESXi 5.5 Update 2 (build 2068190)
• ESXi 6.0 (build 2494585)

В качестве средства создания нагрузки взяли IOmeter, размещенный в виртуальной машине с двумя vCPU, 4 ГБ памяти и Windows Server 2012 в качестве гостевой ОС. Было также сконфигурировано 2 дополнительных виртуальных диска на контроллере PVSCSI:

Для IOmeter было создано три профиля нагрузки, размер Working Set - 100 МБ (204800 секторов). Малый размер Working Set был выбран для более быстрого прогрева кэша.

Результаты (кликабельно):

Как мы видим, VSAN 6.0 показал себя лучше при всех типах нагрузки - выжимает больше IOPS и имеет меньшую задержку (latency), а именно:

• Нагрузка 100% READ | 100% RANDOM: +37% IOPS | -27% latency
• Нагрузка 65% READ | 60% RANDOM: +53% IOPS | -35% latency
• Нагрузка 100% WRITE | 100% RANDOM: +25% IOPS | -24% latency

Производительность снапшотов

VSAN 5.5 (он же 1.0) использует формат vmfsSparse, который, по-сути, является redo-логом. В версии VSAN 6.0 появился новый формат снапшота vsanSparse, который использует механизм redirect-on-write (подробнее тут).

Тест проводился просто - запустили IOmeter (профиль 3) и последовательно снимали снапшоты, наблюдая производительность с помощью VSAN Observer.

Светло-серые картинки - это VSAN 1.0 (5.5), а темно-серые - VSAN 6.0 (кликабельно). Обратите внимание, что значения по осям X и Y на картинках не всегда соответствуют.

Итак, Latency:

Кстати, временами по latency VSAN 6.0 хуже своей предыдущей версии.

По IOPS результаты интереснее:

При создании нагрузки в виде снапшотов VSAN 6.0 снижает производительность по IOPS на 8%, а вот предыдущая версия VSAN - на 49%. Преимущества нового формата очевидны.

Полоса пропускания (Bandwidth):

Интересный эффект - в VSAN 1.0 существенно увеличивается трафик на чтение после снятия каждого снапшота, при этом у VSAN 6.0 такого не происходит. Еще одно улучшение Virtual SAN 6.0.

В целом можно отметить, что производительность кластеров VSAN заметно возрасла, ну а оптимизация снапшотов улучшит и производительность процессов, использующих эту технологию (например, резервное копирование).

Мы уже немало писали про технологию Transparent Page Sharing (TPS) в VMware vSphere, которая позволяет дедуплицировать страницы оперативной памяти на хост-сервере ESXi при недостатке физической памяти для виртуальных машин. Как мы уже писали тут и тут, в VMware vSphere 5.5 Update 3 и более поздних версиях технология TPS отключена (при дедупликации страниц между машинами), чтобы не нагружать хост понапрасну, поскольку в современных ОС используются большие страницы памяти (Large Memory Pages), вероятность дедупликации которых мала. В то же время, технологию TPS никто из vSphere не убирал, и ее можно в любой момент включить.

Как пишет знаменитый Дункан, В VMware vSphere 5.x есть 4 состояния памяти для хост-сервера относительно параметра minFree:

• High (100% от minFree)
• Soft (64% от minFree)
• Hard (32% от minFree)
• Low (16% от minFree)

Эти состояния определяют срабатывание определенных триггеров (об этом ниже). Например, если minFree для вашей конфигурации сервера равно 10 ГБ, то при переходе в состояние, когда занято 6,4 ГБ (Soft), произойдет определенное действие с точки зрения техник оптимизации памяти.

В то же время, триггеры не срабатывают жестко по этим пороговым значениям, а плавно включаются перед ними и плавно выключаются за ними, чтобы не вызвать резких изменений.

Например, при переходе из состояния High в Soft, большие страницы памяти "разламываются" на обычные, чтобы TPS мог их тут же дедуплицировать. Однако, это может сказаться не лучшим образом на производительности - у хоста и так возникает недостаток памяти, а тут еще его нагружают дедупликацией.

Поэтому в VMware vSphere 6.0 ввели новое состояние Clear (100% от minFree), а состояние High переопределили до значения 400% от minFree. Для чего это сделано? А вот для чего.

При недостатке памяти, хостом ESXi используется техника разламывания больших страниц памяти на обычные страницы, которые затем могут быть дедуплицированы с помощью TPS. Это делается затем, чтобы предотвратить свопирование страниц на диск, что является самым тормозным способом освобождения ресурсов. Так вот эта штука начинает активно работать при наличии свободной памяти в промежутке от High (400%) до Clear (100%), чтобы начать работать на еще не испытывающем острого недостатка ресурсов хосте. Но при этом TPS сразу не запускается.

Давайте посмотрим на таблицу:

Это красивое решение - начать разламывать страницы заранее и не нагружать теряющий свободную память хост.

Но все что касается TPS, актуально только тогда, когда TPS включено. По умолчанию же эта техника выключена, а о том, как включить ее, написано вот тут.

Неадвно мы писали о новых возможностях средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN 6.0, где одной из таких возможностей стала возможность конфигурации All-Flash кластера VSAN (то есть, когда и для кэша, и для данных используются SSD-диски):

Естественно, эта штука работает намного быстрее, чем раньше, поскольку прежде данные можно было размещать только на HDD-дисках. Но насколько это стало быстрее?

Чтобы показать некоторые цифры на практике, компания VMware провела тест на bootstorm - ситуацию, когда множество десктопов загружаются одновременно (например, в начале рабочего дня). Для этого была использована следующая конфигурация:

• 64 высокопроизводительных узла кластера Virtual SAN исключительно на SSD-дисках (All-Flash).
• 6401 виртуальных ПК (то есть по 100 каждом хосте), которые включаются одновременно.

Результаты теста оказались весьма позитивными:

• За 24 минуты все виртуальные ПК загрузились.
• Еще за 16 минут все десктопы получили IP-адреса и были готовы к работе.

В итоге все заняло 40 минут. Для почти шести с половиной тысяч машин это весьма и весьма неплохой результат. Кроме того, отмечается, что команда VMware не использовала никаких специальных настроек или модификаций ПО - тест работал, что называется, "из коробки".

Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.

Компания VMware на днях выпустила очень интересный документ "VMware Horizon 6 RDSH Performance and Best Practices", в котором можно почитать о производительности механизма удаленного доступа RDSH в инфраструктуре виртуальных ПК VMware Horizon View 6.

В качестве тестового окружения использовалась инфраструктура VMware vSphere, в которой были запущены виртуальные машины с доступом через Microsoft Remote Desktop Services Host (RDSH) на базе гостевой ОС Windows 2012 R2 Server. Каждой машине было назначено от 2 до 16 виртуальных процессоров (vCPU) и от 16 до 96 ГБ оперативной памяти.

Эти машины взаимодействовали с клиентскими машинами (тоже виртуальными) по протоколу PCoIP. Каждая клиентская машина имела доступ к консоли виртуального ПК и определенному набору приложений. Конфигурация клиентской машины - 32-битная Windows 7 и 1 ГБ памяти:

Схема тестирования выглядела следующим образом:

В качестве средства генерации нагрузки использовался VMware View Planner, который измерял показатели для следующей модели награузок:

• Group-A: Interactive operations
• Group-B: I/O Operations
• Group-C: Background load operations

Нас больше всего интересуют операции группы B. Там замерялось время выполнения следующих конкретных сценариев:

• Adobe Acrobat Reader 10 open PDF file
• Microsoft Internet Explorer 11 open a file served by Apache, open a file in a Web album
• Microsoft Office 2010:
  • Excel open and save file
  • PowerPoint open a file
  • Word open and save a file
• Microsoft Outlook 2010 open program and save an attachment
• Mozilla Firefox 3.6 open file

Вот какие получились результаты по времени выполнения данных операций в зависимости от числа виртуальных ПК на ядро процессора хост-сервера:

Желтая линия - пороговое значение в 6 секунд, при котором время выполнения одного из действий описанных выше, приемлемо для пользователя. Таким образом, на хост описанной выше конфигурации влезет до 9 виртуальных ПК с данной моделью нагрузки.

Взглянем на загрузку процессора при увеличении числа пользователей (виртуальных ПК) на ядро процессора хост-сервера:

Процессор стабильно держит до 9-10 пользователей на одно ядро физического сервера.

Число сессий опробованных приложений из группы операций B на ядро:

В документе присутствует еще очень много интересных результатов, например, использование полосы пропускания различными протоколами доступа к виртуальному ПК (по-сути, плюс-минус все одинаково):

Скачать документ "VMware Horizon 6 RDSH Performance and Best Practices" можно по этой ссылке.

Наверняка, немногие из вас знают, что недавно компания VMware выпустила минорный апдейт своей платформы для создания инфраструктуры виртуальных ПК Horizon View 6.0.2.

В общем-то, ничего особо примечательного, однако новых возможностей в обновлении оказалось не так уж и мало для небольшого апдейта:

• Появились улучшения Windows Media Multimedia Redirection (MMR).
• Добавилась поддержка технологии HTML Access для десктопов RDS.
• Scanner redirection - перенаправление сканера в виртуальный ПК.
• Сохраняемые настройки для location-based printing (при отключении пользователя от десктопа).
• Технологическое превью технологии HTML Access для десктопов, работающих как vDGA.

Были обновлены только следующие компоненты:

• Horizon View Agent (64-bit и 32-bit)
• HTML Access Web Portal installer
• Horizon View HTML Access Direct-Connection
• Horizon View GPO Bundle

Компоненты View Connection Server, Security server, View Composer, View Persona Management и View Agent Direct-Connection (VADC) Plug-in остались без изменений.

Самая интересная новая возможность - улучшения Windows Media Multimedia Redirection (MMR). Напомним, что эта техника позволяет производить обработку видео и аудиопотока на стороне клиентского устройства, задействуя его мощности. То есть, медиапоток в нативном формате сжимается и перенаправляется с виртуального ПК на клиентский ПК, где он потом разжимается и рендерится.

В прошлых версиях технология MMR поддерживалась только в Windows XP, Windows Vista и Windows 7. Теперь же ее можно попробовать также в Windows 8 и Windows 8.1. Кроме того, тепер воспроизведение MMR возможно не только через Windows Media Player (WMP), но и в браузере Internet Explorer через WMP plug-in.

Также для MMR была существенно расширена поддержка форматов видео и аудио, и теперь она включает в себя следующие форматы:

• MPEG-1, MPEG-2 и MPEG-4 Part 2
• WMV 7, 8 и 9
• WMA, AVI, ACE, MP3 и WAV

Скачать обновленную версию VMware Horizon View 6.0.2 можно по этой ссылке.

Многие пользователи VMware Virtual SAN (VSAN), когда проводят тест бэкапа одной виртуальной машины, замечают, что время резервного копирования этой ВМ существенно больше, чем таковое для машины, размещенной на дисковом массиве.

Дункан в своем блоге подробно разбирает эту проблему. Тут дело вот в чем - когда вы используете дисковый массив, то виртуальная машина "размазывается" по дискам RAID-группы, что позволяет читать одновременно с нескольких дисков. Это дает хорошую производительность операции резервного копирования для одной машины.

Кластер же VSAN работает немного по-другому. Это объектное хранилище, в котором виртуальный диск ВМ хранится на одном хосте и его реплика существует на втором. Кроме этого, есть кэш на SSD-диске (но его еще нужно "прогреть"). То есть выглядит все это следующим образом:

Соответственно, при бэкапе одной виртуальной машины данные читаются только с двух HDD-дисков, а не с нескольких как в традиционной архитектуре дисковых массивов, при этом сам кластер VSAN может состоять из нескольких хостов (до 32 узлов). То есть, это архитектурное ограничение.

Однако если мы будем делать одновременный бэкап нескольких виртуальных машин с хранилища Virtual SAN время этой операции уже будет сравнимо с дисковым массивом, поскольку будет задействовано сразу несколько дисков на каждом из хостов, плюс хорошо прогреется кэш. Поэтому проведение такого теста (ведь он ближе к реальным условиям) и было бы более показательным при сравнении Virtual SAN и традиционных хранилищ.

То же самое относится и к VDI-инфраструктуре на базе VSAN - многие пользователи отмечают, что первая фаза операции Recompose (когда создается реплика - полный клон ВМ) отрабатывает весьма медленно. Однако если вы делаете много таких операций - кэш прогревается, и одновременное создание нескольких клонов начинает работать заметно быстрее в расчете на одну машину.

На конференции TechEd Europe 2014 компания Microsoft не только сделала несколько интересных анонсов, касающихся облачной платформы Azure, но и выпустила занимательный документ "Windows Server Technical Preview Step-by-Step Guide Storage Quality of Service".

Напомним, что в новой версии платформы Windows Server vNext от компании Microsoft появится механизм Storage Quality of Service (QoS) - возможность динамического отслеживания производительности хранилищ и горячая миграция виртуальных машин при превышении этими хранилищами пороговых значений (IOPS). Все это делается на базе заранее настроенных политик. По-сути, это аналог механизма Storage DRS от компании VMware в продукте vSphere.

В этом документе от Microsoft на 16 страницах объясняется работа механизма Storage QoS и как его использовать для мониторинга производительности хранилищ и выравнивания нагрузки (забавное понятие "Noisy neighbor mitigation").

Содержание документа:

• Summary
• Goals & Behaviors
• Background
• Scenario 1: Enabling Storage QoS and basic performance monitoring
• Scenario 2: Creating and monitoring with policies
• Known Issues

Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:

• Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
• Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).

Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.

Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.

Нажимаем Add Capacity:

Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):

Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):

Настройка Virtual Flash Host Swap

Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.

Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":

Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":

После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).

Настройка VMware Flash Read Cache (vFRC)

Напомним, что это кэш только на чтение данных, операции записи будут производиться на диск, минуя флэш-накопители. Соответственно, такой кэш улучшает производительность только операций чтения.

Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.

Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:

Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.

По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):

Чтобы понять, какие значения SSD-кэша можно и нужно выставлять для виртуальных машин, рекомендуется почитать документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5".

На сайте проекта VMware Labs появилась интересная утилита ESXtopNGC Plugin, позволяющая получить функциональность консольного средства мониторинга производительности esxtop прямо в vSphere Web Client.

Возможности VMware ESXtopNGC Plugin:

• Отдельные вкладки для статистик процессора, памяти, сети и дисковой подсистемы.
• Гибкий вывод данных, в том числе в пакетном режиме.
• Удобный и гибкий выбор необходимых счетчиков.
• Полнофункциональное представление статистик с возможностью сортировки колонок, раскрытия строчек и т.п.
• Настраиваемый период обновления данных.
• Статистики по виртуальным машинам (VM-only stats).
• Встроенные тултипы с описаниями назначений счетчиков.

Плагин ESXtopNGC на данный момент работает только с виртуальным модулем vCenter Server Appliance (vCSA) 5.5 или более поздних версий.

Для установки плагина загрузите его в одну из директорий на vCSA и выполните там команду:

unzip ESXtopNGCPlugin.zip -d /usr/lib/vmware-vsphere-client/plugin-packages/esxtop-plugin
/etc/init.d/vsphere-client restart

После этого в vSphere Web Client на вкладке "Monitor" для хостов появится представление "Top".

Скачать VMware ESXtopNGC Plugin можно по этой ссылке.